This invention relates generally to the installation of software applications on a computer system, and more specifically, to upgrading a software application program on a computer system.
Software application installation is an area of increasing importance. Unfortunately, existing installation technologies fail to address all of a computer user""s needs. Most installation technologies are simply brute-force mechanisms for copying program files from one location to another. Only one known installer program, Microsoft Windows Installer, developed by Microsoft Corporation, Redmond, Washington, even comes close. For a description of Microsoft Windows Installer, see Kelly, Mike, xe2x80x9cGain Control of Application Setup and Maintenance with the New Windows Installerxe2x80x9d, Microsoft Systems Journal, pp. 15-27, September 1998.
The one installer program that comes closes to addressing all of a computer user""s needs manages the installation of an application so that information related to of each of the application""s resources is stored in a xe2x80x9cconfiguration database.xe2x80x9d The configuration database may be registry keys within a system registry, or it may be a stand-alone database. The stored information includes, but is not limited to, the installed state of the application, i.e., what features of the application are or are not installed, whether the application should be run locally or run from a source, paths to the program files of the application, whether features are xe2x80x9cadvertisedxe2x80x9d (i.e., available but not installed), etc. The stored information is stored at install time and is used by the installer program to ensure that an application always has available the resources that it expects or that the user requests. For instance, one function of the installer program is to verify the existence of a resource needed by the application. When the application requests a path to a program file, the installer program verifies the existence of that program file at the expected location stored in the configuration database. If, for some unexpected reason, the program file does not exist at the expected location, the installer program installs the program file prior to returning its path to the application. The installer program continually updates the configuration database if any changes are made to the installed state of the application.
Once installed, there may be a need to change an application. Generally speaking, changes to an application may be minor, in which case a patch is desirable, or changes may be more significant, in which case an upgrade is desirable. For example, patching may be performed if an application is in need of a service release or update to remedy a programming bug or other infirmity, whereas an upgrade will be performed for a new release. The present invention is directed to upgrades, as opposed to patches. There are several problems with traditional methods of upgrading software applications.
First, traditional methods of upgrading software applications modify the resources of the application, but do not modify the configuration database maintained by the installer program to reflect those modifications. For example, an upgrade will often add a new program file to the application. However, the upgrade does not modify the configuration database to make the installer program aware of the existence of the new program file. In addition, the installer program is unable to update its configuration database to reflect the existence of the new file because the upgrade and new file were not installed by the installer program. The result is that the installer program is unaware that the new program file was added, so any additional functionality provided by the installer program is unavailable for that new program file. For example, the installer program is unable to verify the existence of the new program file if requested by the application.
Another problem with traditional methods of upgrading software applications is that they may not be able to properly upgrade an uninstalled or partially-installed application. At installation, the user may choose not to install all of the features of an application, but rather delay the installation of certain features until they are actually used. The installer program may provide an application with the ability to offer the feature as available although the feature is not installed (xe2x80x9cadvertisingxe2x80x9d the feature). When the user or application attempts to access that feature for the first time, the installer program automatically installs the advertised feature. This reduces the amount of storage space consumed by features of an application that are not initially used.
Yet another problem with traditional upgrades is that there is not a standard. This forces authors to create custom upgrade logic. This in itself is a significant problem, however, the problem is compounded in that this custom logic trickles down to the user. This means that upgrades of different products may have different installation procedures from the perspective of a user.
Accordingly, there exists a need in the art for an improved method of upgrading a software program that provides standardization from the perspective of both the author of the upgrade and the user installing the upgrade. In addition, a need exists for a method of upgrading a software program that can determine if any older versions of the software program are installed and act accordingly. Furthermore, the actions taken, i.e., current install state of the software program, should be stored.
The present invention is directed to a method, and computer-readable medium for upgrading an application using an installer program. The installer program recognizes that an upgrade to the application has been initiated. The upgrade includes an identifier for the application to be upgraded, as well as information required for the installer to perform the upgrade. The installer program accesses the upgrade information which includes instructions necessary for installing the upgrade. The installer program also accesses information related to the installed state of the application and related applications. The installer program determines whether or not the upgrade should be performed. If the upgrade should be performed, the installer program performs the upgrade and stores the fact that the application has been upgraded. Preferably, this is accomplished by unregistering the previously installed application and registering the upgrade, i.e., newly installed application.
In accordance with other aspects of the invention, the application is identified using a unique identifier known as a product code. Alternatively, the application is identified using a product-identifying triplet composed of an upgrade code, a version number, and a language code.
In accordance still other aspects of the invention, the installer program determines if there are newer versions of the product installed. If there are newer versions of the product installed, a default is set so that the upgrade is not installed. Preferably, this default can be overridden. If there are not newer versions of the application installed, the upgrade should be installed.
In accordance with further aspects of the invention, the installer program checks to see if there are previous versions of the product or related products installed. If there are previous versions of the product or related products installed, the installer program determines if the upgrade can coexist with the previous version or related products. If the upgrade can not coexist with previous versions of the product or related products, the previous version or related products that can not coexist with the application upgrade, are removed. Preferably, the installer program presents the user options based on this information. For example, if two products can not coexist, a message is displayed to the user. The user can decide whether to remove the installed version of the product and install the upgrade, or cancel the upgrade without removing the installed version of the product.
In accordance with still further aspects of the invention, the upgrade includes an upgrade table. The upgrade table includes a list of entries for products related to the application upgrade. Each entry provides directions specifying how the related product is to be treated. For example, whether previous products or related products can coexist with the upgrade. Preferably, each upgrade table entry includes: an upgrade code; a version number; a language code and an attribute field. An example attribute field is a coexist value.